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ABSTRACT 


This  memo  describes  a  practical  application  within  the  framework 
of  the  ARPA  computer  network  of  the  philosophy  that  a  fully 
developed  computer  network  should  appear  as  a  virtual  extension 
of  tne  user's  own  software  environment.  The  application 
involves  the  design  and  implementation  of  a  software  facility 
that  will  permit  users  at  MIT's  Dynamic  Modeling  System  to 
consider  the  retrieval  component. ci  the  Datacomputer  (daveloped 
and  run  by  the  Computer  Corporation  of  America)  as  an  extension 
of  the  Muddle  environment.  This  facility  generates  efficient 
Datalanguage  retrieval  code,  handles  inter-process  control  of 
the  Datacomputer,  and  manages  all  the  necessary  network 
connections . 


This  memo  reproduces  a  thesis  of  the  saoe  title  submitted  to  the 
Department  of  Electrical  Engineering,  M.I.T.,  on  May  20,  1974, 
in  partial  fulfillment  of  the  requirements  for  the  Degree  of 
Bachelor  of  Science. 
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INTRODUCTION 

The  efficient  use  of  computing  resources  has  been 
historically  one  of  the  primary  concerns  of  computer  scientists. 
The  efforts  in  this  direction  have  run  along  two  parallel  paths, 
the  one  being  the  optimization  of  the  sharing  of  hardware 
resources  (computing  power),  and  the  other  the  increasingly  core 
important  area  of  the  sharing  of  software  resources.  The  former 
problem  forced  the  trend  away  from  dedicated  systems  and  towards 
the  multi -programmed,  multi-access  computer  that  is  now  in 
common  use  in  virtually  every  application  branch  of  data 
processing.  But  nftlt’ -programmed  systems  per  se  do  not  provide 
an  appronriate  framework  within  which  to  approach  the  software 
problem.  In  particular: 

(a)  Because  the  number  of  users  that  have  access  to  a 
single  raultiprograraned  facility  is  limited  in  size,  and  U^ause 
the  demand  for  different  applications  is  varied,  the  degree  of 
specialization  of  any  single  facility  remains  restricted  within 
well-defined  boundaries. 

(b)  Because  of  this  size  limit,  the  access  to  the  number 
of  software  resources  is  again  limited.  Computer  manufacturers 
alleviate  this  problem  by  providing  a  set  of  'software  packages* 
that  are  found  to  be  useful  in  many  applications.  But  this 
approach  not  only  limits  the  user  to  the  facilities  of  a  single 
manufacturer,  but  often  to  the  type  of  hardware  available  to  his 


from  that  manufacturer. 
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(c)  It  is  important  that  the  sharing  of  resources  not  be 
'cumbered  with  time  delavs  (including  those  associated  with 
tance).  Users  separated  by  great  distances  but  having 
lilar  goals  in  common  need  to  stay  directly  abreast  with  the 
oe\  elcpments  in  their  particular  areas  of  interest. 

It  was  such  considerations  as  the  above  that  have  led  to 
the  interest  in  and  the  development  of  computer  networks.  By 
linking  together  many  computers  so  that  the  resources  of  each 
are  readily  available  from  every  other  site,  the  number  of 
resources  available  to  any  individual  user  is  immediately 
increased.  By  making  ea:h  resource  potentially  available  to 
this  widely  expanded  set  of  users,  the  economies  of  scale  b  in 
to  make  specialization  within  rv ch.  Finally  the  linkage  oi 
computers  provides  a  communication  medium  among  users  that  will 
allow  the  necessary  interaction  that  forms  the  basis  of  software 
sharing . 

A  primitive  computer  network  appears  to  the  user  as  a 
collection  of  distinct  computing  resources  (each  with  its  own 
set  of  nuances)  linked  together  through  some  communication 
medium.  Use  of  foreign  resources  requires  familiarity  with 
foreign  software  procedures  as  well  as  with  the  mechanics  of 
gaining  access  to  these  resources.  By  contrast,  it  1$  desirable 
that  foreign  resources  appear  as  a  logical  extension  of  each 
user's  cjmputing  environment.  This  memo  describes  the  design 
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and  implementation  of  a  software  facility  that  will  allow  the 
users  of  the  HIT  Project  RAC  Dynamic  Modeling  System  [1]  to 
consider  the  retrieval  component  of  the  Computer  Corporation  of 
America  Datacomputer  [2,  3]  as  a  logical  extension  of  the  DflS 
Muddle  environment  [4].  In  particular  it  will  allow  the  users 
at  HIT-DMS  to: 

(a)  ignor :  the  management  of  network  connections  to  the 
Datacomputer ; 

(b)  ignore  the  management  of  inter-process  control  of 
the  Datacomputer; 

(c)  form  retrieval  requests  from  any  database  at  the 
Dalacompute*  using  Ruddle  syntcx,  translating  from  that  syntax 
into  the  Datalanguage  code  that  the  Datecomputer  requires  for 
retrieval . 

This  facility  follows  upon  similar  efforts  in  the  past, 
but  it  is  far  superior  to  them  in  terms  of  generality, 
programming  consistency,  and  adequacy  of  Datalanguage  code 
generated . 

This  incorporation  of  the  Datacorputer  into  the  Ruddle 
environment  not.  cnly  is  desirable  from  t,ie  point  of  view  of  the 
user  at  RIT-DRS  (since  it  accepts  syntax  that  he  is  familar 
with),  but  also  for  the  general  network  user:  it  is  more 
convenient  t“  r~ogram  the  Datacomputer  with  this  facility; 
furthermore  the  addition  of  the  “front-end"  processing  power  of 
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Huddle  to  the  Datacomputer  provides  to  the  network  user  a 
facility  in  its  own  right  that  is  unique  to  the  network. 

OUTLINE 

Chapter  I  describes  the  characteristics  of  the  ARPA 
network  and  the  type  of  problems  that  one  faces  when  attempting 
to  link  resources  within  that  network.  Chapter  II  discusses  the 
two  resources  that  are  to  be  linked  together  (Huddle  and  the 
Datacomputer)  and  the  syntactic  and  semantic  characteristics  of 
each.  The  translation  system  is  then  discussed  in  full  in  the 
third  chapter,  with  examples  and  scenarios  included;  comparison 
with  previous  systems  is  made,  Finally  Chapter  IV  concludes  the 
memo  and  gives  some  suggestions  for  further  development  of  such 
a  facility 
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L.  IHE  ARPANET 

Undoubtedly  the  most  .ur<Mtious  effort  being  made  in  the 
area  of  computer  networks  is  with  the  Advanced  Research  Projects 
Agency  Computer  Communication  Network  (ARPANET),  This 
geographically  distributed  network,  originally  Unking  some 
twenty  computers  when  it  first  better  operational  in  1970, 
currently  supports  well  over  40  such  hosts  spanning  the  distance 
from  Hawaii,  across  continental  United  States,  to  London, 
England.  Its  chief  characteristic  (as  de  from  its  geographical 
distribution)  is  that  it  connects  widely  differing  computer 
systems  which  share  in  common  only  the  capability  to  support 
local  multiprogramming. 

The  ARPANET  interconnects  a  multitude  of  sites,  each 
site  consisting  of  a  maximum  of  four  computer  systems  and  one 
coranunication  computer  (IMP).  I’he  IHPs  of  the  network  (each 
linked  to  a  maximum  of  five  others)  provide  the  necessary 
standardization  and  in  general  are  responsible  for  message 
traffic  control  across  the  network.  An  IHP  also  forms  the 
interface  between  eat  the  computer  systems  and  the  network 
as  a  whole. 

Standardization  throughout  the  network  is  also  provided 
by  a  ser1r  of  layered  protocols,  i.e.  a  set  of  agreements 
between  different  processes  as  to  the  format  through  which  they 
are  to  locate,  synchronize,  and  exchange  information.  Currently 
the  ARPANET  supports  three  levels  of  protocols: 
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(a)  bottom-level  IHP-IPiP  and  HQST*lfiP  protocols  to 
manage  the  flow  o  information  across  the  network  (i.e.  control* 
rout*ng,  etc , )  [5,  6]; 

(b)  a  HOST-HOST  protocol  for  the  creation  of  v4  tual 
process-process  connections  between  processes  residing  on 
different  hosts  [7]; 

(c)  function-oriented  process-process  protocols  to 
support  specific  tasks  (such  as  the  "Telnet  protocol,"  [8]  "file 
transfer  protocol  (FTP),"  [9]  and  the  "remote-job  entry 
protocol"  [ 10]) . 

It  is  the  problems  associated  with  the  last  set  of 
protocols  that  concern  us  here.  In  particular,  if  remote 
facilities  are  ever  to  be  viewed  a  a  virtual  extension  of  each 
host  on  the  network,  this  set  i  protocols  will  have  to  be 
handled  automatically  by  communicating  processes  at  the  two 
remote  sites,  with  the  user  unaware  of  their  existence.  The 
implementation  of  such  a  facility,  in  which  a  program  as  opposed 
to  a  human  user  is  directly  manipulating  a  foreign  service, 
brings  with  it  its  own  particular  problems.  Specifically,  for 
most  time-shared  computers,  the  set  of  responses  generated  by 
the  system  assume  a  human  user  at  the  other  end  who  will  use  his 
own  intelligence  to  act  upon  the  responses  he  has  received. 
Responses  usually  are  coded  in  natural  language  (e.g.  "xyz 
loading"),  are  often  unsynchronized  (e.g.  "system  goinn  down"). 


arc  often  associated  with  the  nuances  of  particular  hosts 
(prompt  characters,  etc.). 

The  approach  to  the  solution  of  this  problem  has  been 
the  adoption  of  vdtat  might  be  termed  the  user-server  paradigm: 
tne  server  site  passively  accepting  coceacnds  the  user  and 
type-coding  its  responses  to  inform  the  user  of  the  state  that 
it  is  currently  ir.,  to  provide  him  with  necessary  informational 
messages  that  he  wy  wish  to  act  upon,  and  to  inform  him  when 
errors  have  occurred  (and  if  possible  their  severity  so  that 
_^propriate  action  right  be  taken)  The  FTP  protocol  is  an 
example  of  t*r  aopliccticr  of  such  a  par*digta,  and  shall  soo 
thf  t  the  Datacomputer ,  by  using  this  paradigm,  allows  us  to 
incorporate  it  as  a  virtual  extension  of  a  Kuddls  process . 
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Ii.  IHE  7V0  SYSIL5S 

THE  DATACQMPUTER 

rhe  Datacomputor  is  an  information  storage  and  retrieval 
service  operated  by  the  Computer  Corporation  cf  America  to  serve 
the  general  ARPANET  community.  Designed  eventually  to  provide 
over  a  trillion  bits  of  storage  online,  this  developing  system 
is  planned  to  become  one  of  the  major  stores  of  information  for 
the  network. 

The  Datacoiaputer  is  particularly  suited  for  the 
management  of  highly  structured  information  such  as  that  found 
in  transportation  reservation  schedules  or  weather  databases, 
where  the  structure  of  'he  information  is  equally  as  important 
as  its  content.  To  the  staggering  amount  of  storayo  capacity  is 
added  the  capability  to  rapidly  retrieve  subsets  of  the  stored 
rj<5?a  according  to  either  its  stru  wural  organization  or  its 
content . 

The  Datacooputer  is  purely  a  storage  device  with  no 
"front-end*  processing  capabilities  (beyond  the  retrieval  of 
information).  This  is  a  disadvantage,  since  interest  in 
structured  data  often  goes  beyond  the  inaJvidual  items  and  to 
the  aggregate;  we  speak  of  "batting  averages. *  "total  Jays  of 
ur.shine,"  "per  cent  of  time  up,"  eve.  Unless  such  values  (i.e. 
average,  t.'.tal,  por  cent)  are  explicitly  stored  in  the  database, 
the  user  must  rely  on  another  processing  facility  in  order  to 
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arrive  at  these.  In  short  the  Datacooputcr  lacks  a  front-end 
statistical  package. 

Information  at  the  Dat.acooputer  is  stored  in  a 
hierarchical  structure.  Central  to  the  ’understanding  of  this 
structure  is  the  notion  of  a  "container."  Fig.  1  shows  a 
typical  container  structure  of  a  hypothetical  database 
concerning  HIT'S  Project  HAC.  Fig.  2  snows  the  actual 
realization  of  this  description  in  a  Datacowputer  file. 
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FJGUk‘  1:  A  container  structure 
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Fiji  MAC  UST 

PERSONNEL  STRUCT 
AI  STRUCT 

STUDENTS  LIST  (4*) 
STUDENT  STRUCT 
NAME  SLR  (10) 
YEAR  STR  (2) 
STATE  STR  (10) 
SALARY  STR  (3) 
*ND 

FACS  UST  {  6 > 

FAC  STRIJl r 

NAME  UR  (10) 
RANT.  STR  (10) 
STATE  SJR  (10) 
SALARY  STR  (3) 
END 
END 

ML  STRUCT 

STUDENTS  UST  (40) 
STUDENT  STRUCT 
NAME  STR  (10) 
YEAR  SJR  (2) 
STATE  SLR  (10) 
SALARY  STR  (3) 
END 

FACS  USI  (20) 

FAC  STRUCT 

NAME  SJR  (10) 
RANK.  5TR  (10) 
STATE  SJR  (10) 
SALARY  SJR  (3) 
END 
END 
END 


FIGURE  2:  A  Datacoaputer  Hie  description 
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In  fig  2  we  note  that  the  containers  come  in  three 
typos:  STRing,  STRUCTur e.  and  UST.  An  STR  contains  a  fixed 
length  string  of  ASCII  characters  (the  lei.;;;,  of  the  string  of 
characters  is  specified  inside  the  parentheses  following  th* 

STR) .  Currently  the  Dataconputer  will  score  only  fixed  length 
ASCII  strings,  but  it  will  eventually  support  other  types  of 
da'  a . 

A  LIST  contains  other  containers  „  T* 

description.  Thus  a  list  description  of  the  for®: 

HOSTS  ysi 
HOST  STR  (3) 

will  contain  a  list  of  host  numbers. 

A  STRUCT  contains  c  her  containers  but  not  necessarily 

of  identical  description.  ^  STRUCT  is  useful  in  Baking  logical 

connections  between  items  in  a  database  as  well  as  providing  a 

naming  mechanism  (the  two  concepts  are  of  course  interrelated) . 

All  the  above  is  a  reflection  of  information 

organization  cf  a  file,  not  of  the  file  itself.  Conceptually  we 

may  think  of  the  following  file: 

BALLPLAYERS  USJ 
BALLPLAYER  STRUCT 
NAME  SJR  (16) 

BATTING -AVERAGE  SIR  (3) 

end 

as  beirn'  a  list  of  ballplayers  and  their  associated  batting 
averages.  An  entry  in  such  a  list  (e.g.  *  Babe  Ruth320*) 
would  be  referred  to  as  a  list  member  whiU  each  field  in  the 
entry  (i.e  the  r.dfle  field  (t'be  Ruth)  and  tne  batting  average 
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fi°ld  (320))  are  referred  to  as  list  member  elements. 

The  basic  statement  used  for  retrieval  by  content  from 
the  Datacoroputer  is  the  FOR  stateaer.t.  Logically  taking,  the 
FOR  statement  is  a  universal  quantifier  over  the  list-sseabers  of 
a  list- 

V(X  €  LISTX' ,  P(X) 

where  P(x)  is  a  set  of  connected  predicates  th_'  * ach  list 
member  must  satisfy  before  being  added  to  an  output  list.  The 
predicates  that  the  Datacomputer  understands  are  EQ  (aqua1  or 
identity),  NE  (not  equal  or  not  identity*,  LT  (less  than),  LE 
(less  than  or  equal  to),  GT  (greater  than),  and  GE  (greater  than 
or  equal  to).  The  logical  connectives  that  it  recognizes  arc 
AND,  OR,  and  NOT. 

The  FOR  statement  in  reality  is  a  bit  ao> e  complicated 
then  the  above.  Specifically,  a  user  programing  in 
Datalenguage  must  explicitly  describe  the  format  of  the  output 
list,  which  for  efficiency  should  match  the  list-members  that 
are  output.  Additionally  a  user  aay  specify  which  STRs  or 
STRUCTs  within  a  list  he  wishes  to  see  from  each  list-member 
that  satisfies  the  given  predicate.  For  example,  we  may  wish  to 
know  the  names  of  the  ballplayers  who  have  a  batting  average 
greater  than  300,  but  we  may  not  be  interested  in  seeing  the 
batting  average  itself;  in  totality  the  Datalanguage  program  for 
such  a  request  would  take  the  form: 
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output  ysj 

N.TM  STR  (15). 

FOR  OUTPUT .  mn ,  3ALLP1  AYERS .  BALLPLAYER 
WITH  BATTING-AVERAGE  G1  *300 * 

NO?i= WAJ1E ; 

END; 

Ihe  first  two  lines  above  would  create  an  appropriate  output 
port  with  only  one  field  (the  name  field  to  be  returned);  note 
that  the  names  that  are  given  to  the  different  containers  need 
not  match  the  names  from  the  file  that  are  to  be  retrieved.  The 
last  three  lines  effectively  say:  for  every  list-setter  of  the 
ballplayers  list  with  batting  average  eleuent  greater  than  300, 
add  the  NAME  element  to  the  output  list  OUTPUT. 

MUDDLE 

The  Huddle  programing  language  is  a  direct  outgrowth  of 
LISP  It  was  designed  by  members  of  the  MIT  Artificial 
Intelligence  Laboratory  and  the  Programing  Technology  Div?«ion 
of  MIT  Project  as  an  environment  within  which  PLANNER  and 
Planner-like  languages  might  run.  Its  chief  advantages  over 
LISP  are  more  data  types,  more  readable  syntax,  ease  of 
extensibility,  network  interfacing  primitives,  and  a  base  for 
advanced  graphics  work. 

Muddle  has  been  running  at  MIT-DMS  for  the  past  three 
years.  During  this  period  it  has  beer,  continually  auspeented; 
this  process  continues  as  now  areas  of  research  are  identified 


and  explored. 


19 


8eyond  the  l>3ss  features  of  Huddle,  the  BBS 

implementation  provides  access  to  a  general  dynaaieslly-loadable 

fuddle  Library."  This  library  consists  of  a  set  of  Actions 

and  global  data  which  users  say  access  in  building  up  tor. 

complex  programs  out  of  other  users'  previous  work.  Within  this 

library  are  such  items  as  a  general  context-free  parser  for  BNF 

grammars  and  a  graphics  package  for  display  consoles.  A  Huddle 

compiler  is  also  implemented  in  order  to  speed  the  processing  of 
debugged  code. 
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ill,  the  TRANSLATION  SVg:EH 

The  translation  system  (HDC-Programaer,  or  HDC  for 
short)  is  capable  of  formulating  retrieval  requests  for  an 
arbitrary  database  at  the  Datacosputer.  HOC  oust  be  aade  aware 
of  the  format  of  each  database  at  the  Datacomputer  fro*  which  a 
user  may  want  to  retrieve  data.  This  is  done  by  creating  a  file 
containing  a  model  (description)  of  the  rarticular  Datacomputer 
file’s  structure.  This  model  is  creat'd  and  stored  at  the 
Dynamic  Modeling  System.  A  user  who  wishes  to  use  the  retrieval 
system  need  only  identify  to  it  the  local  DHS  file  where  the 
database  model  is  stored.  The  modal  encompasses,  in  addition  to 
all  the  information  found  in  a  Datacomputer  file  description,  a 
few  other  items  which  are  used  to  provide  a  more  convenient  user 
interface.  The  process  of  creating  the  model  file  is  relatively 
easy  and  straightforward,  and  it  need  only  be  done  once  for  eich 
new  Datacomputer  database  from  which  wo  wish  to  retrieve 
information.  Appendix  )  contains  the  format  of  such  a  model 
along  with  a  sample  model  file. 

Given  that  a  Datacomputer  file  and  its  corresponding  DKS 
model  file  exist.  HDC- Programmer  when  loaded  will  connect  to  the 
Datacomputer  (using  the  standard  network  Initial  Connection 
Protocol  [11]),  perform  the  LOGIN  for  the  current  user,  and  open 
the  appropriate  file  for  reading.  If  successful  in  all  three, 
HDC  will  build  a  series  of  functions  bearing  the  simple  names  of 
all  the  containers  in  the  Datacomputer  file  model. 
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The  functions  that  are  available  to  the  user  (beyond  the 
primitives  of  Muddle  and  any  functions  that  he  j*ay  have  defined 
or  used  from  the  library)  are  these: 

(a)  A  set  of  functions  bearing  the  simple  names  of  all  the 
containers.  These  functions  ire  used  to  create  the  predicate 
that  the  output  list  members  must  satisfy. 

(b)  A  series  of  functions  that  move  a  pointer  inside  the 
model  of  the  database;  the  position  of  the  pointer  is  crucial  in 
determining  what  actions  the  set  of  functions  in  (a)  are  to 
perform.  The  functions  that  manipulate  the  pointer  are  shown 
here  in  muddle  syntax: 

<PTOP>  /Position  the  pointer  at  .op  of  model." 

<R>  /Move  pointer  one  position  to  the  right." 

<L>  ; "Move  pointer  one  position  to  the  left." 

<DR>  /Move  point ar  down  one  level  to  the  right." 

<DL>  /Hove  pointer  down  one  level  to  the  left." 

<UR>  /Move  pointer  up  one  level  to  the  right." 

<UL>  /Move  pointer  up  one  level  to  the  left." 

(c)  REQUEST  function  that  is  used  to  specify  the  associated 
LIST  member  elements  that  are  to  be  returned  for  each  LIST 
member  satisfying  the  predicate. 

(d)  An  EXECUTE  command  that  will  return  to  he  user  a  Muddle 
channel  from  which  the  information  that  has  bee.:  retrieved  is  to 
be  read.  The  EXECUTE  command  alone  actually  interacts  with  the 
Oatacomputer.  It  starts  a  compilation  process  that  generates 


71 


Datalanguage  code  according  to  the  specifications  Bade  by  the 
above  sets  of  functions,  transmits  that,  code  to  the 
Dnacomputer ,  and  returns  a  channel  on  which  the  requested  data 
is  waiting  to  be  read. 

(e)  A  set  of  "convenience  conoands"  which  allow  the  user  to 
enter  different  Bodes,  specify  a  change  of  file  froa  the  one 
currently  being  processed,  display  the  substructure  that  the 
pointer  points  to,  display  or  suppress  the  set  of  Datacomputer 
control  responses,  etc. 

It  should  be  noted  that  the  position  of  the  pointer 
determines  the  actions  to  La  taken  by  the  various  functions  in 
the  set  (a)  above.  Application  of  one  of  the  functions  will 
send  the  flDC -Programmer  through  an  exhaustive  search  of  that 
part  of  the  file  model  currently  at  the  pointer.  The  search 
restricts  the  values  of  the  data  returned  frea  each  container 
bearing  the  name  of  the  function  to  the  values  specified  in  the 
argument  of  the  function.  For  example,  the  application  of  the 
function : 

< STATE  ( "HASS" )> 

for  a  file  with  the  description  of  that  in  figure  3  will  have 
the  following  results  depending  on  whether  the  pointer  is  at 
ptrl,  ptrZ,  or  ptr3: 

(a)  If  at  ptrl,  this  requires  all  the  /alues  of  the  field 
ofATE  within  the  list  MAC  to  be  ■  RASS*  (the  padding  is 
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necessary  because  the  data  is  stored  in  fixed  length  fields; 
MDC-Programmer  will  pad  appropriately  for  the  user).  TMs  would 
be  used  for  example  in  a  request  such  as  "Which  people  at 
Project  Mac  come  from  Massachusetts?" 

(b)  If  at  ptr2,  this  requires  all  the  values  of  the  field 
STATE  within  the  AI  group  to  be  "  MASS",  as  in  "Which 
people  from  the  AI  group  are  from  Massachusetts?" 

(c)  If  at  ptr3,  this  requires  all  the  values  of  the  field 
STATE  for  the  students  within  the  AI  group  to  be  Massacnusetts . 
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FILE  MAC  LIST 

PERSONNEL  STRUCT  <*==ptrl 

AI  STRUCT  <===ptr2 

STUDENTS  LISI  (40)  <«:ptr3 

STUDENT  STRUCT 
NAME  SJR  (10) 

YEAR  SJR  (2) 

STATE  STR  (10) 

SALARY  SIR  (3) 

END 

FACS  UST  (20) 

FAC  STRUCT 
NAMF  SIR  (10) 

RANK  SIR  (10) 

STATE  SIR  (10) 

SALARY  Slh  (3) 

END 

END 

ML  STRUCT 

STUDENTS  LISI  (40) 

STUDENT  STRUCT 
NAME  SIR  (10) 

YEAR  5TR  (2) 

STATE  SIR  (10) 

SALARY  STR  (3) 

END 

FACS  USJ  (20) 

FAC  STRUCT 

NAME  STR  (10) 

RANK  SIR  (10) 

STATE  SIR  (10) 

SALARY  SIR  (3) 

END 

END 

END 


FIGURE  3.  A  Datacoaputer  fila  description  with  pointers 
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The  actions  of  these  functions  also  depend  or  tho  iype 
of  container  that  the  function  name  refers  to  (the  containers 
being  the  ones  unambiguously  located  by  the  above  procedure). 

In  the  pointer  examples,  all  the  containers  were  STRs  and  the 
action  taken  was  as  described.  However  if  the  container  turns 
out  to  be  a  STRUCT,  the  arguments  of  the  function  are  passed  (in 
order)  to  each  container  within  the  STRUCT.  This  procedure  is 
recursive,  allowing  STRUCTs  to  be  embedded  within  other  SPncTs. 
For  the  description  in  fig.  2,  a*'  application  of  the  function 
<STUDt«7  i ( ■JOHN">(r73"))> 
i*  equivalent  to  the  application  of  the  functions 

<NArtE  ( “JOHN" )> 

<.YEAR  ( "73"  )> 

Note  that  any  previous  statement  about  other  fields  that 
place  restrictions  on  the  LIST  members  that  are  to  be  returned 
remain  unaffected.  If  we  wished  to  specify  those  students  named 
John  with  salaries  equal  to  500  (irrespective  of  their  YEAR  or 
STATE),  this  would  be  done  in  the  following  manner  by  using  a 
null  list  in  the  position  of  the  YEAR  and  STATE  fields: 

•(STUDENT  ( ( "JOHN* )( )( ) ( 500 ) ) > 

If  the  function  name  refers  to  a  LIST,  the  arguments  are 
passed  down  again  as  with  STRUCT,  but  this  time  to  the  one 
(there  can  be  only  one)  container  that  the  list  encloses. 

Strictly  speaking,  functions  bearing  the  names  of  USTs 


and  STRUCTs  are  not  necessary.  However,  they  are  important. 
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because  it  is  in  terns  of  these  containers  (as  well  as  the  Sifts) 
that  the  user  thinks  about  his  data;  they  provide  an  additional 
convenience  of  raak^ig  one  function  call  instead  of  several;  and 
finally  they  allow  the  user  to  rorolve  simple  nase  asfciguity 
without  moving  the  position  of  the  pointer. 

The  set  of  container  name  functions  can  also  take 
arguments  Involving  the  predicates  that  the  Datacomr^ter 
understands  (in  the  above  examples  the  implicit  predicate  was 
EQ),  linked  together  by  the  connective  'OR'.  Thus  application 
of  ♦he  following  function  is  acceptable: 
v STUDENT  ( ( "JOHN"  OR  "JACK" ) 

(LT  mnm  OR  GE  "75"))> 

This  would  returr  “hose  students  named  Jack  or  John  who 
graduated  before  73  or  who  will  graduate  after  74. 

The  REQUEST  command  is  used  to  specify  which  elements  of 
oach  1 1  ST -member  from  the  output  list  are  to  be  returned.  The 
format  of  the  REQUEST  command  is  as  follows: 

(REQUEST  4name>  4name>  ..,> 

where  4name>  refers  to  the  names  of  the  containers  that  are  to 
be  returned.  These  simple  names  are  resolved  in  terms  of  the 
description  pointer  as  was  done  with  the  container  name 
functions.  If  (name>  refers  unambiguously  to  an  $Jg,  the  SXE 
values  are  returned;  if  (name>  refers  unambiguously  to  a  STRUCT, 
all  elements  within  that  STRUCT  are  returned;  finilly  if  4natw> 
refers  unambiguously  to  a  UST,  all  the  elements  of  each  list 
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member  are  returned. 

The  EXECUTE  command,  applied  simply  as 
<EXECUTE> 

starts  the  actual  retrieval  process.  This  process  is  a  two  pass 
algorithm.  The  first  pass  builds  an  appropriate  port 
description  for  output,  and  the  second  pass  uses  that 
description  in  the  formulation  of  an  appropriate  Oat,  language 
request  statement.  Both  passes  are  recursive,  allowing  file 
models  to  have  arbitrary  embedding  of  containers  and  thus 
capable  of  processing  any  file  that  could  conceivably  be  stored 
at  the  Datacomputer  (for  version  0/9). 

PROCESS-PROCESS  COMMUNICATION 

Communication  with  the  Datacomputer  is  done  through  the 
user-server  paradigm  discussed  earlier  in  this  memo.  The 
Datacomputer  will  sit  passively,  interpreting  Datalanguage 
coranands  and  sending  out  information  to  the  user  site  specifying 
the  actions  that  ^re  being  taken  as  a  result  of  these  commands. 
This  set  of  information  messages  is  sent  out  one  line  at  a  time. 
The  first  five  characters  of  a  response  line  are  a  message  code 
intended  to  be  used  by  a  foreign  program,  while  the  remainder  of 
the  line  is  the  natural  language  equivalent  of  this  code  for 
human  interpretation. 

The  class  of  responses  sent  by  the  Da c? computer  fall 


broadly  into  three  areas: 
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(a)  Informational  messages 

(b)  s^r.^ronization  messages 

(c)  error  messages 

The  first  character  of  each  response  line  determines  the 
class  witr'n  which  each  message  falls.  Error  messages  are 
further  subcategorized  according  to  severity,  so  that  the  user 
site  may  take  appropriate  action.  Typical  synchronization 
messages  are  "waiting  for  datalanguage  input,"  "waiting  for 
data,"  et ; .  Some  informational  messages  are  "adding  node  to 
table,"  "execution  complete,"  etc.  Error  messages  can  be  either 
compilation  or  execution  errors.  In  the  latter  case,  a  series 
of  messages  will  follow,  describing  the  actions  taken.  These 
actions  may  vary  from  "temporary  ports  flushed"  to  "crashing 
user  job."  F.ach  error  message  is  then  followed  by  a 
synchronization  message  which  will  allow  the  two  processes  to 
get  back  ikuo  step  after  having  lost  control  through  an 
unexpected  event. 

COMPARISON  WTTH  PREVIOUS  SYSTEMS 

Two  e» forts  along  similar  lines  preceded  this  one. 

These  were  'XIkRET  [12]  written  by  the  author,  and  SMART  written 
by  Hal  Murray  at  Computer  Corporation  of  America. 

Every  twenty  minutes,  a  program  at  the  Dynamic  Modeling 
System  wakes  up  to  record  the  statuses  of  the  different  hosts 
across  the  network.  The  prograi  collects  this  information  and 
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stores  it  in  the  SURVEY  database  at  the  Datacomputer.  This 
information  proved  to  be  of  interest  to  the  general  network 
community,  so  a  task-specific  Huddle-to-Datalanguage  programmer 
was  written  for  retrieving  this  information.  It  was  the  success 
and  usefulness  of  this  facility  that  brought  about 
considerations  for  a  general  huddle-to-Datalanguage  programmer . 

SrIART  was  a  prompt-response  system  for  generating 
datalanguage  code  from  the  set  of  responses  made  by  the  user. 
There  are  two  chief  difficulties  with  the  whole  concept  of  a 
prompt-response  system.  One  is  that  as  the  number  of  containers 
in  a  file  tend  to  increase,  the  system  becomes  an  increasingly 
more  difficult  interface  for  the  user,  as  he  may  have  to  L»e 
prompted  unnecessarily  for  a  large  number  of  fields.  The  second 
difficulty  is  that  the  prompt-response  is  not  a  consistent 
embeoding  of  the  system  within  a  larger  software  environment; 
such  an  approach  fragmentizes  resources  as  opposed  to  unifying 
them  into  more  powerful  facilities. 

SMART  is  not  a  fully  general  system.  Specifically  it 
will  not  handle  any  files  with  embedded  lists  within  them.  Its 
usefulness  is  thus  restricted  to  a  vtry  small  subset  of  the 
potentially  rich  information  structures  that  the  Datacomputer  is 
capable  of  handling.  In  addition,  making  SMART  intelligent 
enough  to  retrieve  information  from  a  new  file  description 
requires  about  three  days  of  system  progracoer  time.  HDC- 
Programmer  improves  this  performance  in  two  respects.  \1)  The 
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task  of  acquiring  tiie  capabilities  to  process  a  new  file  does 
not  require  the  intervention  of  a  systems  programmer.  It  is 
simple  enough  so  that  any  user  who  knows  the  file  structure  can 
create  the  model  file.  (2)  This  process  for  creating  the  file 
model  takes  on  the  order  of  minutes  as  opposed  to  days. 

SCENARIO 

A  sinpl«  scenario  of  HDC- Programmer  in  use  is  outlined 
below.  It  is  a  transcript  of  an  actual  session  made  at  the 
Dynamic  Modeling  System.  In  this  session,  retrieval  of 
information  is  made  from  two  files:  PEOPLE  as  given  in  the 
example  database  in  appendix  1,  and  SURVEY  as  given  in  figure  4 
The  former  file  was  created  for  testing  purposes  whereas  the 
latter  is  a  "real"  file  which  is  accessed  quite  often  to  get 
information  regarding  .he  past  performance  of  various  hosts  on 
the  network.  The  underlined  lines  below  represent  tho^e  that 
have  been  typed  in  by  the  user;  the  indented  lines  have  been 
included  for  explanatory  purposes;  the  lines  beginning  with  a 
period  or  semi-colon  are  responses  from  the  Datacomputer ;  all 
other  lines  are  what  Muddle  prints  or  returns  as  a  result  of 
function  application. 

LISTENING-AT-LEVEL  1  PROCESS  1 

Message  from  Muddle  indicating  it  is  listening  for  commands 
<FLOAD  "SABiM-DO* 
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Above  function  will  load  HOC  (the  $  sign  typed  in  by  the 
user  starts  the  evaluation  by  huddle). 

Huddle  to  Datalanguage  Translator 
Please  type  name  of  losal  file  containing 
Datacomputer  file  taojcl: 

VSAB ; PEOPLE  FILE'S 

HDC  greeting  message  followed  by  a  string  typed  in  by  the 
user  identifying  the  pathname  of  the  file  containing  the 
model  of  the  Datacooputer  file  PEOPLE. 

; J 1 50  21-05-74  0034:43  FCRUN:  HERE  WE  GO 
; J200  21-05-74  0034:43  RHRUN:  READY  FOR  REQUES" 

.  1210  21-05-74  0034:43  LAGC:  READING  NEW  DL  B'JI  FER 


Datacomputer  greeting  message;  it  is  now  ready  to  receive 
coranands---first  the  user  must  be  logged  in. 


LOGIN  NAME  PLEASE: 

Typed  out  by  HDC  to 

"MIT. DFS. SURVEY »S 
;J209  21-05-74  0035:09 
; J200  21-05-74  0035:10 
.1210  21-05-74  0035:10 


prompt  user  for  login  name. 


RHRUN :  EXECUTION  OHPLETE 
RHRL'N :  READY  FOR  R  OflJEST 
LAGC:  REAu/Ti  NEW  Dl  SUFFER 


Login  is  completed.  Not'4  *h*t  the  user  is  ^'Jrrently  in 
UNSOAR  mode,  i.e.  the  responses  of  the  Datacomputer  are 
displayed  at  his  console.  He  can  vary  ts*s  mode  (to  one  in 
which  the  Datacomputer  responses  are  not  displayed)  by 
application  of  the  function  SOAR. 


;U000  21-05-74  0075:25 
; J209  21-05-74  0035:28 
;  J200  21-05-74  0035:28 
.1210  21-05-74  0035:28 
"DONE" 


DHKD:  ADDING  PUNCTUATION 
RHRUN:  EXECUiiON  COMPLETE 
RHRUN:  READY  FOR  REQUEST 
LAGC:  READING  NEW  DL  BUFFER 


The  four  Datacomputer  lines  are  in  response  to  the  opening 
of  the  PEOPLE  file;  the  open  was  successful;  the  last  line 
was  returned  by  Muddle  indicating  that  loading  of  HDC  has 
been  completed. 

<CONTEXT>$ 

CONTEXT  is  a  function  which  will  show  the  file  tsodel  to  the 
user  below  the  point  where  his  pointer  is  currently  located. 
Immediately  following  loading,  the  pointer  will  always  point 
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to  the  top  of  the  model.  After  pr  Hng  the  model,  CONTEXT 
will  then  return  the  pathname  of  the  pointer. 

(PEOPLE 

LIST 

() 

(PERSON 

STRUCT 

0 

(NAME  STR  ()) 

(ADDRESS  STR  ()) 

(CITY  STR  ()) 

(STATE  STR  ()) 

(ZIP  STR  ()) 

(DEPENDENTS 

LIST 

O 

(DEPENDENT  STRUCT  ()  (NAME  STR  ())  (AGE  STR  ( )))))) 

"PEOPLE" 

<TERSE>$ 

"DONE" 

Enters  the  user  into  terse  mode;  i.e  after  applying  the 
container  name  functions  or  the  REQUEST  function  or  the 
EXECUTE  function,  the  model  will  not  be  printed  but  rather 
only  the  pointer  pathname  will  be  returned. 

(REQUEST  ‘VMIU'/S 
■PEOPLE" 

Request  is  made  for  all  names  within  the  file;  since  the 
pointer  is  currently  at  the  top  of  the  model,  all  the  names 
of  the  children  as  well  as  the  adults  will  be  returned. 

(SET  CH  < EXECUTE >>S 

; J209  21-05-74  0046:07  RHRUN:  EXECUTION  COMPLETE 
;  J200  21-05-74  0046:07  RHRUN:  READY  FOR  REQUEST 
.1210  21-05-74  0046 : C8  LAGC:  READING  NEW  DL  BUFFER 

This  set  of  Datacoraputer  responses  is  made  in  response  to 
the  creation  of  an  output  port.  In  reality  the  entire 
Datalanguage  program  has  been  to  the  Datacomputer,  but 
^synchronization  occurs  at  the  i.axt  request.  The  following 
code  was  sent  to  the  Datacomputer : 

■CREATE  L2  TEMP  PORT  LIST 
ST 1  STRUCT 
S2  STR  (15) 

LI  USX  (0,  2),  D*'*' 
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SI  §TR( 15) 

END 

followed  by  the  request: 

■  FOR  C2.ST1, PEOPLE. PERSON 
S2=NAME; 

FOR  LI .SI # PEOPLE . PERSON . DEPENDENTS . DEPENDENT 
SUNAME; 

END; 

end;" 


and  Muddle  returns: 

#CHANNEL  [4  "READ*  -1  -1  "NET"  0  5688  13893763  "NET"  4127  4118 
23748359936  < ERROR  END-OF-FILE! -ERRORS)  0  0  0  0  10  ••] 

the  channel  returned  by  the  EXECUTE  command. 

<F ILECOPV  .CH  .OUTCHAN)S 

FILECOPY  is  a  Huddle  function  which  copies  data  from  one 
channel  to  another;  in  this  case  it  is  copying  the  data 
coning  from  the  Dataconputer  to  the  user  console  output 
channel,  giving: 

BILL  STORH  * 

ALICE  FALL  JILL  FALL  * 

SCOTT  SUMMER  MARY  SUMMER  * 

138 


The  above  are  the  names  returned;  the  was  specified  in 
the  generated  Datalanguage  code  to  separate  the  occurrences 
of  inner  list  members.  In  this  manner  we  know  that  Jill 
Fall  is  a  dependent  and  that  Mary  Summer  is  a  dependent. 

The  138  at  the  end  is  a  count  of  the  number  of  characters 
that  have  been  received  over  the  channel;  it  is  returned  by 
FILECOPY.  The  next  request  will  be  to  ask  for  the  address 
of  Scott  Summer.  Here  however  things  will  be  done  in  SOAK 
mode  so  that  the  Datacoaputer  responses  will  no  longer 
appear. 

<SOAK>$ 

"DONE" 


<NAHE  ("SCOTT  SUMMER" )>S 
"PEOPLE" 


<REQUEST  (STATE  ADDRESS ))S 
"PEOPLE" 
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<SET  CH  <EXECUTE>>S 

^CHANNEL  [4  "READ"  -1  -1  "NET"  0  6512  13893763  "NET*  4127  4118 
23748359936  < ERROR  END-OF -FILE! -ERRORS)  0  0  0  0  10  ”] 

< F i LECOPY  .CH  ,QUTCHAN)S 
HA  9  BOW  STREET 
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9  BOW  STREET  ano  ttA  were  found  as  the  address  of  Scott 
Summer  in  the  order  requested:  first  the  state,  then  the 
street  address.  The  character  count  is  apain  returned  by 
FILECOPY.  Note  that  for  these  examples  we  did  not  need  our 
pointer  functions  (primarily  because  of  the  simplicity  of 
the  file);  performance  of  these  functions  is  shown  below. 

<CVAL>S 

"PEOPLE" 

Clear  all  values;  the  file  model  now  looks  like  it  did  when 
we  first  loaded  HOC. 

<DR>$ 

"PEOPLE. PERSON" 

<DR>$ 

"PEOPLE. PERSON. NAME* 

<R  5>$ 

“PEOPLE . PERSON . DEPENDENTS" 

<CONTEXT)S 

(DEPENDENTS 

LIST 

0 

(DEPENDENT 

STRUC 

0 

(NAME  STR  ()) 

(AGE  STR  ()))) 

" PEOPLE . PERSON . DEPENDENTS" 


( Y74Q1  LIST  () 

(LOG TRY  STRUCT  #FALSE( ) 

(DAY  STR  ()  #FALSE( )  2  !"0  T  T  1  31) 

(MONTH  STR  ()  #FALSE( )  2  !a0  T  T  1  12) 

(YEAR  STR  ()  #FALSE()  2  !"0  T  T  73  74) 

(HRrllN  STR  ()  #FALSE( )  '  !"0  T  #FALSE( )  #FALSE( )  #FALSE( )) 
(HOST  STR  ()  #FALSE()  3  !*0  T  T  0  6) 

(STATUS  STR  ()  #FALSE( )  1  #FALSE( )  #FALSE( )  T  0  6) 

(SOC  STR  ()  #FALSE( )  3  #FALSE()  #FALSE( )  #FALSE( )  #FALSE( ) 
#FALSE()) 

(SCHED  STR  !  )  #FALSE( )  1  #FAL5E( )  #FALSE( )  #FALSE( )  #FALSE( ) 
#FALSE()) 

(RESTIME  STR  ()  #FALSE()  3  !"0  T  #FALSE( )  # FALSE ( )  #FALSE( )))) 


FIGURE  4:  SURVEY  database  asodel 
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(NEWFILE  "SAB;SURVi.  FILE">$ 


A  change  from  the  file  from  which  information  is  to  be 
retrieved  is  done  by  the  NEWFILE  command;  the  argument  to 
the  command  must  be  the  pathname  of  the  DM5  file  where  the 
new  Datacomputer  file  model  is  stored. 

"Y74Q1- 

(CONTEXT)S 
( Y74Q1 
LIST 
() 

(LOGTRY 

STRUCT 

0 

(DAY  STR  ()) 

(MONTH  STR  ( )) 

(YEAR  STR  ()) 

RMIN  STR  ()) 

(HOST  STR  ()) 

(STATUS  STR  ()) 

(SOC  STR  ()) 

(SCHED  STR  ()) 

(RESTIME  STR  ()))) 

"Y74Q1" 

This  survey  file  contains  all  the  "irvey  information  for  the 
first  quarter  of  1974. 

<HOST  (31)  >S 
M Y74Q 1 " 

<HRMIN  (GT  500  AND  LT  600)>S 
"Y74Q1M 

(MONTH  y 1 ) >S 
"  Y7'iQl " 


(DAY  [LT_41>$ 

"Y74Q1 " 

(REQUEST  1 LOGTRY ) >S 
"Y74Q1 " 

(SET  CH  ,EXECUTE>>S 


The  request  was  for  all  the  information  on  host  31  (CCA)  for 
the  tine  period  of  5  o’clock  to  6  o’clock  from  January  1  to 
January  3. 


#CHANNEL  [4  "READ"  -1  -1  "NET"  0  7280  13893763  "NET"  4127  4118 
23748359936  < ERROR  END-OF-FILE! -ERRORS)  0  0  0  0  10  ■•] 


< F I LECOPY  .CH  .OUTCHAN)S 

01017405120315001203! 

010174053203150012034 

010174055203150012031 

020174051003150012032 

0201/4053003150012038 

020174055003150012036 

030174051103150012025 

030174053103140012000 

030174055103150012029 
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The  first  six  characters  of  each  line  are  the  date,  followed 
by  four  for  the  time,  three  for  the  host  number  (031),  one 
for  the  status  (5=logger  available),  three  for  the  socket 
(001),  one  for  the  schedule  (2=unknown),  and  three  for  the 
response  time  in  tenths  of  a  second. 

<CONTEXT)$ 

( Y74Q1 
LIST 
0 

(LOG TRY 
STRUCT 
() 

PAY  STR  (LT  4)) 

(MONTH  STR  (1)) 

(YEAR  STR  ()) 

(HRMIN  STR  (GT  500  .AND  LT  600)) 

(HOST  STR  (31)) 

(STATUS  STR  ()) 

(SOC  STR  ()) 

(SCHED  STR  ()) 

(RESTIME  STR  ()))) 


The  datalanguage  code  fo»-  retrieval  ly  content  in  this 
example  was: 

"  FOR  LI .ST1 , Y74Q 1 .LOG TRY 

WITH  (  DAY  E3  *01*  OR  DAY  Eg  '02'  OR  DAY  EQ  '03')  AND 
(  MONTH  Eg  'Op  AND 

(  HRM1N  GJ  '0500*  AND  HRHIN  LJ  '0600')  £ND 
(  HOST  Eg  '031') 
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IV.  CONCLUDING  REMARKS 

MDC  has  been  fully  implemented,  b'jt  it  has  yot  to  be 
documented  for  the  general  ARPANET  community.  I  believe  that 
when  it  is  documented  and  put  to  use,  it  will  prove  to  be  as 
useful  a  programming  tool  as  SURRET  was  found  to  fca,  but  a  far 
more  powerful  one  because  of  its  generality. 

Continual  Improvement  of  the  facility  must  go  hand  in 
hand  with  the  development  of  the  Datacomputer.  Version  1/0  of 
the  Datacomputer  is  about  to  be  released,  and  it  includes  many 
features  that  the  former  version  did  not  possess.  Tne 
differences  between  the  two  versions  however  indicate  that  a 
major  reprogramming  of  MDC  will  not  be  necessary;  changes  will 
need  to  be  made,  but  to  augment  the  facility  as  opposed  to 
completely  changing  it. 

MDC  currently  provides  both  Muddle  functions  and  the 
retrieval  component  of  the  Datacomputer.  A  major  improvement  to 
the  system  would  be  the  addition  of  a  statistical  package. 

Rather  than  have  U  t  package  programed  in  Muddle,  use  should 
be  made  of  other  sites  on  the  network  (such  as  the  Nultics 
Consistent  System)  which  already  possess  quite  powerful 
statistical  packages.  Taken  together  such  a  system  would  rerve 
as  an  exemplary  model  of  network  resource  sharing,  while  at  the 
same  time  provide  an  opportunity  to  explore  some  areas  of 
network  parallel  processing. 
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APPENDIX  U  HIE  nODEtS 

The  file  model  used  by  ADC -Programmer  is  held  tm\  a 
fluddle  list  structure  (do  not  confuse  with  a  Datacoaputar  LIST) . 
Each  list  has  its  first  object  as  the  name  of  a  container  and 
the  second  object  as  the  type  of  thu  container.  The  regaining 
objects  in  a  list  are  then  dependent  on  the  type  of  container 
that  the  list  represents: 

(a)  For  LISTs  the  third  object  is  always  an  espty  list. 

LISTs  will  also  always  have  a  fourth  element  which  will  be  a 
description  list. 

(b)  For  STRilCTs,  the  third  element  is  either  #FALSE()  or 
specifies  the  length  of  a  LIST  that  say  immediately  enclose  the 
STRUCT  (this  is  done  only  for  embedded  LISTs) .  The  remaining 
objects  of  a  STRUCT  will  be  one  or  more  description  lists. 

(c)  For  bTRs.  the  third  object  is  always  an  empty  li  t.  The 
fourth  object  specifies  the  default  value  of  the  field  or  is  a 
#FALSF().  The  fifth  object  specifies  the  fixed  length  of  the 
field.  The  sixth  object  gives  the  padding  character,  if  any, 
arid  the  seventh  gives  the  direction  of  the  padding  (left  or 
right).  The  eighth  object  states  whether  the  STTl  is  an 
inversion  key  or  not;  if  it  is  and  the  STR  holds  numerical 
values,  the  ninth  and  tenth  objects  will  hold  the  maximum  and 
the  minimum  value  respectively.  The  eleventh  (optional)  object 
performs  the  same  function  as  STRUCT* s  third  object,  but  for  the 
case  where  lists  enclose  only  a  single  STR. 
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Following  is  the  Model  built  for  the  list  PEOPLE  that 


was  used  in  the  SCENARIO  section. 

(PEOPLE  LIST  () 

(PERSON  STRUCT  #FALSE( ) 

(NAME  STR  ()  #FAISE()  15  !*  T  T  #FALSE( )  #F/.LSE()) 

(ADDRESS  STR  ()  #FALSE( )  20  !■  T  #FALSE( )  #FALSE( )  #FALSE( )) 

(CITY  STR  ()  #FALSE( )  10  T  #FAISE( )  #FAL5E( )  #FAISE()) 

(STATE  STR  ()  #FALSE( )  2  #FAISE( )  #FAtSE( )  #FALSE( )  #FALSE( )  #FALSE( ) ) 
(ZIP  STR  ()  #FALSE()  5  #FALSE()  #FALSE( )  IFALSEO  ✓ FALSE ( )  #FALSE( ) ) 
(DEPENDENTS  LIST  () 

(DEPENDENT  STRUCT  2 

(NAME  STR  ()  #FALSE()  \5  !■  T  #FA'.SE( )  #FALSE( )  #FALSE( ) ) 

(AGE  STR  ()  #FALSE( )  2  !"0  T  * FALSE ( )  #FALSE( )  #FALSE( )))))) 
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APPENDIX  l\  PROG RAH  ABSTRACTS 

The  programs  comprising  HOC  reside  in  the  DHS  Huddle 
Library.  Each  program  in  the  Library  has  an  Abstract,  also  in 
the  Library,  that  gives  necessary  and  sufficient  information 
about  the  program  to  allow  direct  use  of  the  program  by  other 
programs  and  to  allow  maintenance  of  the  Library.  This  appondix 
contains  the  Abstracts  for  the  HDC  package  itself  and  for  its 
"ports"  --  those  programs  designed  to  be  called  from  outside  the 
package,  for  example  from  the  user's  console.  For  the  sake  of 
brevity,  Abstracts  for  the  internal  programs  are  not  included 
here . 

The  various  parts  of  an  Abstract  are  n«»ed  by  Huddle 
comments  (preceded  by  a  semicolon),  which  briefly  describe  the 
following  part.  Some  parts  are  in  turn  made  up  of  parts,  in 
hierarchical  fashion.  The  hierarchy  is  defined  by  the  various 
brackets  used  to  enclose  Huddle  objects  in  the  Abstract,  and  it 
is  further  indicated  here  by  indentation. 

Each  Abstract  is  a  Huddle  vector  (enclosed  in  [])  whose 
elements  and  subelements  are  vectors,  strings  (enclosed  in  "), 
lists  (enclosed  in  ()),  type  declarations  (enclosed  in  ()  and 
preceded  by  #DECL),  forms  (enclosed  in  <>),  and  atoms 
(everything  else) . 
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"Unique-name*  "HDC! -PACKAGE" 

"Name"  "HDC* 

"Author"  ["SAB"  "Jll"] 

"Object-type*  "PACKAGE" 

■Contents*  [ 

;  "Ports"  [  "CONTEXT"  "NEWFILE"  "PTOP*  "VERBOCE"  "TERSE"  "SOAK" 

"UNSOAK*  "CVAL"  "CREQUEST*  "R"  CL"  "DR"  "DL"  "Ul"  "UR" 

"REQUEST*  "TINE-CONSTANT"  "CON"  "OIS"  "EXECUTE"  "JNIT"] 

;  "Internal-functions"  ("SIHPLE"  "SIH,  LIFY"  "COISP"  "COHRET" 

"CRESTR*  "CVALUE*  "CREQ*  "PATHNAHw  "INITVAL"  "REQLIST" 

"SETVAL*  "PAD*  "EXPAND*  "RESOLVE*  "aROLSP"  "GETLL"  "GETS" 

"GETST"  "NEXTS*  "STRING EP*  "CRELIST"  "CRESTRUC*  "GETLEN" 

"HAFISH"  "FIL1ST*  "FILISTl"  "FILIST2"  "COHSTR*  "LISTN* 

"COHSTRUC"  "COHLIST"  "RTIHE*  "NETINT*  "ICP"  "CONNECT" 

"GETCODE"  "DCERR*  "PCON"  "EXEC"] 

;  "Data-ports"  [ 

;  "Data-ports-global"  [] 

;  "Data-ports-local"  [#DECL  ( (TIHE. CONSTANT)  FIX) 

"TINE. CONSTANT  determines  how  long  the  ICP  should  wait  for  a 
response  from  the  Datacoaputer. ” ]  ] 

;  "Internal-data*  [  ]  ] 

"Category"  ["NETWORK"] 

"Descriptor*  [ "NETWORK  "DATALANGUAGE"  "DATACONPUTER"  "RETRIEVAL"] 
"External-Interactions*  [ 

;  "Side-effect"  ["I/O"  "IDENTIFIER*  "DATA"  "INTERRUPTS"] 

;  "Variables"  [ 

;  "Global"  [ 

;  "Setg'd"  [#DECL  ((NIN  NOUT)  <OR  CHANNEL  FALSE))] 

:  "Used"  [ADECL  ((NIN  NOUT)  <OR  CHANNEL  FALSE)  (OUTCHAN)  CHANEL)}] 

;  "Local"  [ 

;  "Set"  [#DECl.  ( 

( DFD  DPTR  DSTLST  FD  NUHLIST  PTR  SIHPLENAHE  SUBLIST?  SUBVAL?  STLST)  UST 
(HIDE  SOAK  LC  N  SC  STC  SYNCF  TIHE. CONSTANT)  FIX 
( DLCODE  HESS  PORTDESC  PORTN  SI  TEK1 )  STRING)] 

;  "Used"  [#DECL  ( 

(DFD  DPTR  DSTLST  FD  NUHLIST  PTR  SIHPLENAHE  STLST)  LIST 
(ARGS)  <  SPEC  I AL  ATOH) 

(HIDE  Lt  N  SC  SOAK  STC  SYNCF  TIHE. CONSTANT)  FIX 

(DLCODE  HESS  PORTDESC  PORTN  SI  TEH1)  STRING  (AC1  DONE)  ACTIVATION 

(CHICP)  (SPECIAL  <OR  CHANNEL  FALSE)) 

(INCHAN)  <OR  CHANNEL  FALSE))] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [PPRINT  RTIHE] 

;  "Environment"  [ 

;  "Required"  [] 

;  "During*  [] 

;  'After"  []  ]  ] 

;  "Location"  "LIBRARY" 

;  "Reference"  ["B.S.E.E.  thesis,  S.  A.  Bengelloun,  June  1974"] 
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"Description"  ["This  is  a  general  retrieval  program  for  the 
Datacomputer.  The  user  manipulates  a  user-built  file  node!  to  fora 
a  request  in  Datalanguage.  REQUEST  then  sends  the  Datalanguage 
program  to  the  Datacomputer.  The  information  it  retrieves  can  be 
printed  on  the  user's  console  or  written  into  a  file.*] 

■Argument"  [] 

"Example"  ["See  scenario  in  thesis.8] 

"Notes"  [  ] 
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[ 

;  "Unique-name"  "CONTEXT! -HDC" 

;  "Name"  "CONTEXT" 

;  "Author"  "SAB" 

;  "Object-type"  "FUNCTION" 

;  "Contents*  [] 

;  "Category"  ["UTILITY"] 

;  "Descriptor"  ["CONTEXT"  "ffODEL"  "POINTER"  "OUTPUT"] 

;  "External-interactions"  [ 

;  "Side-effect"  [] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [] 

;  "Used"  [$DECL  ((DPTR)  LIST)] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [ PATHNAME  PPRINT] 

;  "Environment"  [ ]  ] 

;  "Location"  "M)C" 

;  "Reference*  ["KDC"] 

;  "Description"  [■ 

CONTEXT  displays  that  portion  of  the  fils  scdsl  which  is  currently 
to  the  right  of  the  pointer."] 

;  "Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  STRING)  "returns  pethnaae  of  pointer"] 
;  "Argument-type"  [] 

;  "Result-type"  ["STRING"]  ] 

;  "Example"  [<CONTEXT>] 

;  "Notes"  [] 

] 


47 


-Unique-name"  "NEWFILE! -MDC" 

-Marne-  "NEWFILE" 

-Author-  "SAB" 

-Object-type"  "FUNCTION" 

-Contents*  [] 

-Category-  [  "DAT  A -HAN  DUNG"  ] 

-Descriptor"  ["NEW"  "FILE"  "MODEL"  "BINDING"  "CREATION"  "FUNCTION"] 

"Externa] - interactions"  [ 

;  "Side-effect"  ["I/O"  "IDENTIFIER"  "DATA"] 

;  "Variables"  [ 

;  "Global"  [ 

;  "Setg'd"  [] 

;  "Used"  [#DECL  ((NOUT)  <OR  CHANNEL  FALSE))]  ] 

;  "Local"  [ 

;  "Set"  [#DECL  ( 

(DFD  DPTR  DSTLST  FD  PTR  SIMPLENAME  STLST)  LIST)] 

:  "Used"  [#DECL  ( 

(DFD  DPTR  FD  PTR  SIMPLENAME)  LIST  (ARGS)  <SPECIAL  ATOM))] 

;  "Special-  [#DECL  ((ARGS)  ATOM)]  ]  ] 

;  "Functions  called"  [COMRET  SIMPLIFY  CDISP] 

;  "Environment"  [  ]  ] 

;  "Location"  "MDC" 

;  "Reference"  [ "MDC" ] 

;  "Description"  [" 

Newfile  brings  in  a  new  file  model.  It  also  creates  a  series  of 
functions  which  permit  the  user  to  manipulate  the  file  model. 
Specifically,  each  function  provides  a  mechanism  for  changing  the 
value  of  the  list  which  is  associated  with  its  name.  "] 

;  "Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  STRING  STRING)  "erg  is  local  file  name-] 
;  "Argument- type"  ["STRING"] 

;  "Result-type"  "STRING"] 

;  "Example"  [ 

< NEWFILE  "SAB; SURVEY  FILE") 

"The  argument  must  be  the  name  of  a  model  file.  " 

< MONTH  ( JUN )  > 

"MONTH  is  a  created  function  that  modifies  the  field  MONTH  in  SURVEY 
FILE  It  puts  JUN  into  the  list  associated  with  the  field  MONTH."  ] 

;  "Notes"  [] 

] 
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“Unique-name"  "PT0P»-F1DC" 

"Name"  "PTCP" 

■Author"  "SAB" 

"Ob  ject-t'v  pe"  "FUNCTION" 

"Contents'  [] 

■Category"  [ "PROG RAN -CONTROL"] 

■Descriptor1'  ["TOP"  "flODEL"  "GOTO"  "POINTER"] 
"External-interactions"  [ 

;  "Side-effect"  [] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [#DECL  ( (DPTR  D5TL5T  PTR  STLST)  LIST)] 

;  "Used"  [#DECL  ( (DFD  FD)  LIST)] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [COMET] 

;  "Environment"  [ ]  ] 

■Location"  "P1DC" 

■Reference"  [ "HDC" ] 

"Description"  [" 

This  function  moves  the  pointer  to  the  top  of  the  file  sodel.*] 
"Argument"  [ 

;  "Template"  [IDECL  ("VALUE"  STRING)  "returns  pathname  of  pointer"] 
;  "Argument-type"  [] 

;  "Result-type"  ["STRING"]  ] 

"Example"  [<PTOP>] 

"Notes"  [j 
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[ 

;  "Unique-name"  "VERBOSE!  -PlDC" 

;  "Name"  "VERBOSE" 

;  "Author"  "SAB" 

•  "Object-type"  "FUNCTION* 

;  "Contents"  [] 

;  "Category"  ["DISPLAY"] 

;  "Descriptor"  ["CONTEXT"  "POINTER"  "CHANGE"  "OUTPUT"] 

;  "External-interactions"  [ 

;  "Side-effect"  [] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [#DECL  ((HIDE)  FIX)] 

;  "Used"  [] 

;  1  Special"  []  ]  ] 

;  "Functions  called"  [] 

;  "Environment"  [ ]  ] 

;  "Location"  "HDC" 

;  "Referpnce"  [ "HDC" ] 

;  "Description"  [" 

This  function  causes  the  program  to  enter  verbose  node. 

In  this  mode  the  CONTEXT  is  printed  whenever  a  function  returns  the 

pointer  pathname."] 

;  "Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  STRING)  "returns  tae  string  'DONE'"] 

;  "Argument-type"  [] 

;  "Result-type"  ["STRING"]  ] 

;  "Example"  [<VERBOSE>] 

;  "Notes"  [] 

1 
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[ 

;  "Unique-name"  "TERSE! -NDC" 

;  "Name"  "TERSE" 

;  "Author"  "SAB" 

;  "Object-type"  "FUNCTION" 

;  "Contents"  [] 

;  "Category"  ["DISPLAY"] 

;  "Descriptor"  ["CONTEXT"  "POINTER"  "CHANGE"  "OUTPUT"] 

;  "External-interactions"  [ 

•  "Side-effect"  [] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [#DECL  ((HIDE)  FIX)] 

"Used"  [] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [ ] 

;  "Environment"  [ ]  ] 

;  "Location"  "HOC" 

;  "Reference"  [ "HDC" ] 

;  "Description*  [" 

Terse  is  the  noposite  of  verbose.  In  terse  Bode  only  the  pathnaae 
of  the  pointer  is  printed  "] 

;  "Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  STRING)  "returns  the  string  ‘DONE'"] 
;  "Argument-type"  [] 

;  "Result-type"  ["STRING"]  ] 

;  "Example"  [< TERSE)] 

;  "Notes"  [] 

] 


i 
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-Unique-name"  "SOAKI-HDC" 

-Name"  "SOAK* 

-Author*  "SAB" 

-Object-type"  "FUNCTION* 

-Contents"  [] 

-Category"  ["DISPLAY9] 

-Descriptor"  ["OUTPUT"  "DATACOHPUTER"  "RESPONSE"  "CONTROL"] 
"External-interactions"  [ 

;  "Side-effect"  [] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [#DECL  ((SOAK)  FIX)] 

;  "Used*  [] 

;  "Special"  []  ]  ] 

;  -Functions  called"  [ ] 

;  "Environment"  [ ]  ] 

"Location-  "MDC" 

"Reference"  [ "MDC" ] 

"Description"  [" 

Invoking  SOAK  inhibits  th?  printing,  on  the  console,  of  subsequent 
Datacomputer  control  information  sent  across  the  Network 
Connections .  *  ] 

"Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  CTRING)  "returns  the  string  ’DONE'"] 
;  "Argument-type"  [] 

;  "Result-type"  ["STRING"]  J 
"Example"  [<S0AK>] 

"Notes"  [  ] 


"Unique-name"  "UNSOAK! -HOC" 

"Name"  "UNSOAK" 

"Author"  "SAB" 

"Object-type"  "FUNCTION" 

"Contents"  [] 

"Category"  ["DISPLAY"] 

"Descriptor"  ["OUTPUT"  "DATACOflPUTER"  "RESPONSE"  "CONTROL"] 
"External-interactions"  [ 

;  "Side-effect*  [] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [#DECL  ((SOAK)  FIX)] 

;  "Used"  [] 

;  "Special"  []  ]  ] 

;  "Functions  called*  [ ] 

;  "Environment"  [ ]  ] 

"Location"  "MDC" 

"Reference*  [ "MDC" ] 
inscription"  [" 

UNSOAK  negates  SOAK.  Ail  the  control  information  sent  thereafter  by 
the  Datacoraputer  is  printed  on  the  console."] 

"Argument"  [ 

;  "Template"  T #DECL  ("VALUE"  STRING)  "returns  the  string  ’DONE’*] 

;  "Argument-type"  [ ] 

;  "Result-type"  ["STRING"]  ] 

"Fxample"  [<UNSOAK>] 

"Notes"  [  ] 
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"Unique -name''  "CVALI-HDC" 

"Name"  "OML" 

"Author"  "SAB" 

"Object-'ype"  "FUNCTION" 

"Contents"  [] 

"Category"  [ "DATA -HANDLING"  ] 

"Descriptor"  ["CLEAR"  "INITIALIZATION"  "FIELD*  'VALUE*  "MODEL* 
"CRITERION"  "RESTRICTION"] 

;  "External-interactions"  [ 

;  "Side-effect"  [] 

;  "Variables"  [ 

:  "Globa!"  [j 
;  "Local"  [ 

;  "Set"  [] 

;  "Used"  [#DECL  ( (DPTR)  LIST  (PTR)  LIST)] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [CCflRET  CVALUE] 

;  "Environment"  [ ]  ] 

;  "Location*  "ADC* 

;  "Reference"  ["ADC"] 

;  "Description"  [" 

CVAL  clears  ail  the  field  values  from  the  file  Bodel  that  were  set 
by  the  user  with  field-named  functions. *] 

;  "Argument"  [ 

;  "Template"  [#?ECL  (“VALUE"  5TRING  "OPTIONAL*  <OR  FALSE  LIST)  LIST) 
"returns  pathname  of  pointer"] 

;  "Argument-type"  [ "FALSE*  "LIST"] 

;  "Result-type"  ["STRING"]  ] 

;  "Example"  [<CVAL>  ] 

;  "Notes"  [] 

1 


54 


"iinique-nanw*  "CREQUEST' -NDC" 

"Name"  "CREQUEST" 

"Author '  "SAB" 

"Object-type"  "FUNCTION" 

"Contents"  [  ] 

"Category"  [ "DATA -HANDLING"] 

"Descriptor"  ["CLEAR"  "INITIALIZATION"  " REQUEST"  "RESULT"] 
"External-interactions^  [ 

;  "Side-effect"  [] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [] 

;  "Used"  [#DECL  ( (DPTR)  LIST  (PTR)  LIST)] 

;  "Special"  []  ]  ] 

;  "Functions  ..ailed"  [COfTRET  CREQ] 

;  "Environment"  [ ]  ] 

"Location"  "ADC" 

"Reference"  ("NOC"] 

"Description"  ["CREQUEST  clears  all  user-set  REQUEST  fields."] 
"Argument"  [ 

;  "Template"  [#DECL  ( "VALUE*  STRING  "OPTIONAL"  <OR  FALSE  L1ST>  LTST) 
"returns  pathname  of  the  pointer"] 

,  "Argument-type"  ["FALSE"  "LIST"] 

;  "Result  ype"  ["STRING"]  ] 

"Example"  [ 

<CREQUEST> 

"The  optional  ar^nents  are  used  by  internal  functions."] 

"Notes"  [] 
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"Unique -name"  "RI-HDC" 

"Name"  "R" 

"Author"  "SAB" 

"Object-type-  "FUNCTION" 

"Contents"  [] 

"Category"  [ “DATA-HANDLING" ] 

"Doscripto,  "  ["HOVE"  "POINTER"  "RIGHT"  "MODEL"  "CONTEXT"] 
"External-interactions"  [ 

;  "Side-effect"  [“DATA"] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [#DECL  ( (DPTR  PTR)  LIST)] 

;  "Used"  [ADECL  ( (DPTR  DSTLST  STLST)  LIST  (HIDE)  FIX)] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [PATHNAME  PPRINT] 

;  "Environment"  []  ] 

;  "Location"  "HOC" 

;  "Reference"  ["HOC"] 

;  "Description"  [" 

R  moves  the  pointer  tc  the  right  in  the  file  »cod?l."] 

;  "Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  <0R  FALSE  STRING)  "OPTIONAL"  FIX/ 
"returns  pathname  of  pointer"] 

;  "Argument-type"  ["FIX"] 

;  "Result-tyre"  ["FALSE"  "STRING"]  ] 

;  "Example"  [<R>  "moves  the  pointer  to  the  right  1  plat*" 

<R  .FIX)  "moves  the  pointer  to  th^  right  .FIX  places”] 

;  "Notes"  [] 

] 
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"Unique-name"  "l! -HOC" 

"Name"  "L" 

"Author"  "SAB" 

"Object-type"  "FUNCTION" 

"Contents"  [] 

"Category"  ["DATA-HANDIING"] 

"Descriptor"  ["HOVE"  "POINTER"  "LEfT"  *HODEL*  "CONTEXT* ] 
"External  *  interactions"  [ 

;  "Side-effect"  ["DATA"] 

;  "Variables"  [ 

;  "Global"  [] 

" Loc a 1 "  [ 

;  "Set"  [#DECL  ( (DPTR  PTR)  LIST)] 

;  "Used"  [#DECL  ((DPTR  DSTLST  STLST)  LIST  {HIDE)  FIX)] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [ PATHNAME  PPRINT] 

;  "Environment"  [  ]  ] 

"Location"  "HDC" 

"Reference"  ["HOC4] 

"Description"  [* 

L  movps  the  pointer  to  the  left  in  the  file  soda!."] 

"Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  <OR  FALSE  STRING)  "OPTIONAL"  FIX) 
"returns  pathname  of  the  pointer"] 

;  "Argument-type"  ["FIX"] 

;  "Result-type"  ["FALSE"  "STRING"]  ] 

"Example"  [<L>  "moves  pointer  to  the  left  1  place* 

<L  .FIX)  "moves  pointer  to  the  left  .FIX  pieces*] 


Notes"  [] 


"Unique-name"  "DR'-flDC" 

"Name"  "DR" 

"Author"  "SAB" 

"Object-type"  "FUNCTION" 

"Contents"  [  ] 

"Category"  [ "DATA-HANDLING" ] 

"Descriptor"  ["MOVE"  "POINTER"  "DOWN"  "RIGHT"  "MODEL"  "CONTEXT"] 
"External-interactions"  [ 

;  "Side-effect"  [] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  \ 

;  "SAt"  [IDECL  ( ( DPTR  DSTLST  PTR  STLST)  LIST)] 

;  "Used"  [#DECL  ((HIDE)  FIX  (DPTR  DSTLST  PTR  STLST)  LIST)] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [PATHNAME  PpRINT] 

;  "Environment"  [ ]  ] 

"Location"  "HDC" 

"Reference"  ["HOC" ] 

"Description"  [" 

DR  moves  the  pointer  down  and  tc  tie  right  in  the  file  aodel."] 
"Aroument"  [ 

;  "Template*  [#DECL  ("VALUE"  <0R  FALSE  STRING)) 

"returns  pathname  of  the  pointer"] 

;  "Argument-type"  [] 

;  "Result-type"  ["FALSE"  "STRING"]  ] 

"Example"  [<DR>  "moves  the  pointer  down  one  level  to  the  right"] 
"Notes"  [] 
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"Unique -name"  "DLI-NDC" 

"Name"  "DL" 

"Author"  "SAB" 

"Object-type"  "FUNCTION" 

"Contents"  [] 

"Category"  ["DATA-HaNDLING"] 

"Descriptor"  ["HOVE"  "POINTER"  "DOWN6  "LEFT"  "MODEL"  "CONTEXT* ] 
^External-interactions*  [ 

;  "Side-Effect"  [] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [] 

;  "Used"  [#DECL  ( ( DPTR  STLST)  LIST  (HIDE)  FIX)] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [PATHNAME  PPRINT  R  DR  L] 

;  "Environment"  [  ]  ] 

"Location"  "HDC" 

"Reference"  ["HDC"1 
"Description"  [" 

DL  moves  the  pointer  down  and  to  the  left  in  the  file  Model."] 
"Argument*  [ 

;  "Template"  [#DECL  ("VALUE"  <OR  FALSE  STRING)) 

"returns  pathname  if  the  pointer*] 

;  "Argument-type"  [] 

;  "Result-type"  ["FALSE"  "STRING"]  ] 

"Example"  [<DL>  "moves  the  pointer  down  one  level  to  the  left"] 
"Notes"  [] 
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"Unique-name"  "ULI-HDC" 

"Name"  "UL" 

"Author"  "SAB" 

"Object-type"  "FUNCTION" 

"Contents"  [] 

"Category"  [ "DATA-HANDLING" ] 

"Descriptor"  ["HOVE"  "POINTER"  "UP"  "LEFT"  "HODEL"  "CONTFaT"] 
"External-interactions"  [ 

;  "Side-effect"  [] 

;  "Variables"  [ 

.  "Global"  [] 

;  "Local"  [ 

;  "Set"  [#DECL  ((DPTR  DSTLS1  ?r%  STLST)  LIST)] 

;  "Used"  [#DECL  ( ( DPTR  DSTLST  STLST)  LIST  (HIDE)  FIX)] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [PATHNAHE  PPRINT] 

;  "Environment"  [ ]  ] 

"Location"  "flDC" 

"Reference"  [ "HDC" ] 

"Description"  [“ 

UL  moves  the  pointer  up  and  to  the  left  in  the  file  isodel.") 
"Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  COR  FALSE  STRING)) 

"returns  pathname  of  the  pointer’] 

;  "Argument-type"  [] 

;  "Result-type"  ["FALSE"  "STRING"]  ] 

"Example"  [<UL>  "moves  pointer  up  one  level  to  the  left"] 
"Notes"  [  ] 
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"Upi  iQlic -HaTic"  UR'  TIUI' 

■Name*  "UR* 

"Author*  *SAB" 

■Object-type*  "FUNCTION* 

"Contents"  [] 

■Category*  ["DATA-HAWDLING" ] 

"Descriptor*  ["HOVE"  "POINTER"  "UP"  "RIGHT"  "H0DEL"  "CONTEXT"] 
"External-interactions*  [ 

;  "Side-effect"  [ "DATA" ] 

;  ■Variables*  [ 

;  -Global"  [] 

;  "Local"  [ 

;  "Set"  [#DECL  ((DPTR  DSTLST  PTR  STL5T)  LIST)] 

;  "Used"  [#DECL  ( (DPTR  DSTLST  3TLST)  LIST  (HIDE)  FIX)] 

;  "Special"  []  ]  ] 

;  "Functions  called*  [PATWJAHE  PPRINT] 

;  "Environment"  [  ]  ] 

"Location"  "HOC" 

■Reference"  ["HDC" ] 

"Description"  [* 

UR  moves  the  pointer  up  and  to  the  right  in  the  file  model.”] 

;  "Argument"  [ 

;  "Template"  [#DECL  ( ■VALUE*  <OR  FALSE  STRING)) 

"returns  pathname  of  the  po‘  r"] 

;  "Argument-type*  [] 

;  "Result-type"  ["FALSE"  "STRING"]  ] 

;  "Example"  [<UR>  "moves  the  pointer  up  one  level  to  the  right"] 
;  "Notes"  [] 

] 
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"Unique -name"  "REQUEST!  -ri  DC® 

"Name"  "REQUEST" 

"Author"  "SAB" 

"Object-type"  "FUNCTION" 

"Contents"  [  ] 

"Category"  [ "PROGRAM -CONTROL"  "NETWORK" ] 

"Descriptor"  [ "DATACOMPUTER*  "FILE"  "FIELD"  "OUTPUT"  "RESULT"] 
"External-interactions"  [ 

;  "Side-effect"  [] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [] 

;  "Used"  [#DECL  ( (DPTR  D5TLST  PTR  STL5T)  LIST)] 

;  "Special"  [#DECL  ( (STK)  lIST  (N  N)  FIX)]  ]  ] 

;  "Functions  called"  [COKRET  REQLIST] 

;  "Environment"  []  ] 

"Location"  "HDC" 

"Reference"  [ "MDC" ] 

"Description"  [ 

"REQUEST  sets  the  request  field  for  information  retrieval. 

This  field  determines  what  field(s)  of  the  Datacomputer  file  should 
be  output."] 
n Argument”  [ 

;  "Template"  [*DECL  ("VALUE"  STRING  LIST) 

"Argument  1  is  a  list  of  field  names.  Returns  pointer  pathname.*] 

;  "Argument-type"  ["LIST"] 

;  "Result-type"  ["STRING"]  ] 

"Example"  [< REQUEST  (MONTH  DAY  HOST  STATUS)) 

"This  example  is  taken  from  the  SURVEY  FILE.  It  will  cause  the 
Datalanguage  program  to  ask  for  the  date,  host,  and  status  fields.*] 
"Notes"  [] 
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"Unique-name"  "TINE- CONSTANT! -ADC" 

"Name"  "TIME -CONSTANT" 

"Author"  "SAB" 

"Object-type"  "FUNCTION" 

"Contents"  [  ] 

"Category"  [ "PROGRAM -CONTROL" ] 

"Descriptor"  ["TIMEOUT"  "LIMIT"  "MODIFICATION"  "ICP"] 
"External-interaction"  [ 

;  "Side-effect"  [] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [#DECL  ( (TIME. CONSTANT)  FIX)] 

;  "Used"  [] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [  ] 

;  "Environment"  [  ]  ] 

;  "Location"  "MDC" 

;  "Reference"  ["MDC"] 

;  "Description"  [" 

TIME-CONSTANT  is  used  to  control  the  initial  connection  to  the 
Datacomputer .  It  determines  how  long  the  ICP  should  wait  for 
acknowledgement  from  a  foreign  host.  If  this  function  is  not 
called,  the  waiting  period  will  be  20  seconds.*] 

;  "Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  FIX  <UNSPECIAL  FIX>) 

"Argument  is  number  of  seconds.  Retu?  i  nuaber  of  seconds."] 
;  "Argument-type"  ["FIX"] 

;  "Result-typo"  ["FIX"]  ] 

;  "Example"  [<TINE-CONSTANT  60>  "It  wili  wait  for  60  seconds."] 

;  "Notes"  [] 

] 
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t 

;  "Unique-name"  "CQNI-HDC" 

;  "Name"  "CON" 

;  "Author"  "SAB" 

;  "Object-type"  "FUNCTION" 

;  "Contents"  [] 

;  "Category"  ["I/O"] 

;  "Descriptor"  ["CONNECTION"  ■ESTABLISH*  "DATACONPUTER"  "ICP*] 

;  "External-interactions"  [ 

;  "5id°-effect"  ["I/O"] 

;  "Variables"  [ 

;  "Global"  [ 

;  "Setg'd"  [] 

;  "Used"  [#DECL  ((NOUT)  <OR  CHANNEL  FALSE))]  ] 

;  "Local"  [ 

;  "Set"  [#DECL  ( (SYNCF)  FIX)] 

;  "Used"  [ #DECL  ((FD)  LIST)] 

;  "Special"  [#DECL  ((N)  <SPECIAL  STRING))]  ]  ] 

;  "Functions  called"  [DIS  PCON  CONNECT] 

;  "Environment4  []  ] 

;  "Location"  "HDC" 

;  "Reference"  ["HDC"] 

;  "Description"  [" 

CON  attempts  to  establish  Network  channels  to/froa  the  Datacoap «ter ] 
;  "Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  <0R  FALSE  STRING)) 

"returns  the  string  'Connection  to  datacoaputer  coopleted. ' " ] 

;  "Argument-type"  [] 

;  "Result-type"  ["FALSE"  "STRING"]  ] 

;  "Example"  [<CON>  "Invokes  connsction  rites."] 

;  "Notes"  [" 

Normally  CON  will  not  be  needtd.  <INIT)  initializes  the  progran  and 
establishes  the  Network  channe  s."] 

] 
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[ 

;  "Unique-name"  "DISI-MDC" 

;  "Name*'  "DIS" 

;  "Author"  "SAB" 

;  "Object-type"  "FUNCTION" 

;  "Contents"  [] 

;  "Category"  ["I/O"] 

;  "Descriptor"  ["CONNECTION"  "TERMINATE"  "DISCONNECT"  "DATACOMPUTER" ] 

;  "External-interactions"  [ 

;  "Side-effect"  ["I/0Hj 
;  "Variables"  [ 

;  "Global"  [ 

;  "Setg'd"  [] 

;  "Used"  [#DECL  ((NIN  NOUT)  <OR  CHANNEL  FALSE))]  ] 

;  "Local"  []  ] 

;  "Functions  called"  [  ] 

;  "Environment"  [  ]  ] 

;  "Location"  "HOC" 

;  "Reference"  [ "MDC" j 
;  "Description"  [" 

DIS  closes  the  Network  channels  to/froa  the  Datacosputer.*] 

;  "Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  STRING) 

"returns  the  string  'Connection  to  datacoaputer  has  been  severed.'*] 
;  "Argument-type"  [] 

;  "Result-type"  ["STRING"]  ] 

;  "Example"  [<DIS>] 

;  "Notes"  [] 

] 


;  "Unique-name"  "EXECUTE1 -HDC" 

;  "Name"  "EXECUTE" 

;  "Author"  "SAB" 

;  "Object-type"  "FUNCTION" 

;  "Contents"  [] 

;  "Category"  ["I/O"  "NETWORK" ] 

;  "Descriptor"  ["OUTPUT"  "DATALANGUAGE"  "SEND"  * PROGRAM" ] 

;  "External-interactions"  [ 

;  "Side-effect"  ["i/Ow] 

;  "Variables"  [ 

;  "Global"  [ 

;  "Setg'd*  [] 

;  "Used"  [#DECL  { (NOUT)  <OR  CHANNEL  FALSE))]  ] 

;  "Local"  [ 

;  r  Set"  [] 

;  "Used"  [#DECL  ( (PORTN)  STRING  (SYNCF)  FIX)] 

;  "Special"  [ #DECL  ( (AC1 )  ACTIVATION)]  ]  ] 

;  "Functions  called"  [EXEC  PCON] 

;  "Environment"  [  ]  ] 

;  "Location"  "HDC" 

;  "Reference"  ["KDC"] 

;  "Description"  ["EXECUTE  execute.,  .he  REQUEST  to  the  Dstaccaputer . 
;  "Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  COR  CHANNEL  FALSE))] 

;  "Argument-type"  [] 

;  "Result- type"  ["CHANNEL"  "FALSE"]  ] 

;  "Example"  [CFILECOPY  (EXECUTE)  .OUTCHAN) 

"prints  the  information  retrieved  on  the  user's  console"] 

;  "Notes"  [] 
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"Un  ig»io-nam»»"  "INIT'-MDC" 

••N.ino"  "i.NIT" 

"Author"  "SAB" 

"Object- type"  "FUNCTION" 

"Contents"  [J 
"Category"  ["I/O"] 

"Descriptor"  [ " INITIALIZATION"  "SETUP"  "CONNECTION"  "ESTABLISH" 
"ICP"  "DATACOMPUTER"  "LOGIN"  "MODEL"  "FILE"] 

;  "External-interactions"  [ 

;  "Side-effect"  ["I/O"] 

;  "Variables"  [ 

;  "Global"  [] 

;  "Local"  [ 

;  "Set"  [#DECL  ( 

(DFD  r  o  DSTLST  FD  PTR  SIMPLENAME  STLST)  LIST 
(HIDE  SOAK  TIME. CONSTANT)  FIX  (TEN!)  STRING)] 

,  "Used"  [ #DECL  ((DFD  FD)  LIST  (INCHAN)  <OR  CHANNEL  FALSE))] 

;  "Special"  []  ]  ] 

;  "Functions  called"  [CON  INITVAL  SIMPLIFY  CDISP] 

:  "tnvironr:er«i"  []  ] 

;  "Location"  "1DC" 

;  "Reference"  [ "MDC" ] 

;  "Description"  [" 

IN  IT  initializes  the  program  and  sets  up  Network  channels  to/froa 
the  Datacomputer."] 

;  "Argument"  [ 

;  "Template"  [#DECL  ("VALUE"  STRING)] 

;  "Arg  merit- type"  [ ] 

;  "RescU-type"  ["ST&ik']  1 
;  "Example"  [ 

<  I N I T  > 

"It  will  ask  for  the  name  of  a  local  file  containing  a  Datacomputer 
file  description  and  for  a  login  name." 

"SAB; PEOPLE  FII F"  "Tnis  is  a  local  file." 

"MIT. DMS. SURVEY"  "This  is  a  login  rase."] 

;  "Notes"  [  ] 

] 


